문서의 임의 삭제는 제재 대상으로, 문서를 삭제하려면 삭제 토론을 진행해야 합니다. 문서 보기문서 삭제토론 절차적 프로그래밍 (문단 편집) == 단점 == 당연히 단점 또한 존재한다. 기본적으로 프로시저를 호출하는 것은 그냥 코드를 쓰는 것보다 시간이 매우 많이 소모된다. 32비트 Windows 환경의 프로시저 호출에 관여하는 레지스터는 4개로 볼 수 있다. 스택 바닥의 주소를 가지고 있는 EBP, 현재 스택의 주소를 가지고 있는 ESP, 다음 명령어의 주소를 가지고 있는 EIP, 코드 세그먼트 CS인데, CS에 영향을 주지 않는 근거리 함수 호출 및 반환의 경우 다음 과정을 거친다. 1. 스택에 인자를 넣는다. ('''메모리 접근''') 1. 스택에 EIP를 넣는다. (현재 명령어 주소 저장. '''메모리 접근''') 1. EIP에 함수의 주소를 넣는다. (함수의 주소로 이동) 1. 스택에 EBP를 넣는다. (스택 바닥 주소 저장. '''메모리 접근''') 1. EBP에 ESP를 넣는다. (현재 스택의 주소를 새로운 스택 바닥 주소로 함) 1. 함수 실행 (이 과정에서 ESP를 적절히 빼서 지역 변수를 할당할 수 있으며, EBP의 값은 바꾸지 않는다) 1. ESP에 EBP를 넣는다. (함수 호출 전의 스택 주소 복원) 1. 스택을 뽑아 EBP에 넣는다. (함수 호출 전의 스택 바닥 주소 복원. '''메모리 접근''') 1. 스택을 뽑아 EIP에 넣는다. (함수 호출 전의 명령어 주소 복원 후 그 주소로 이동. '''메모리 접근''') 이 중 2~3의 과정은 CALL 명령어에 포함되어 있고, 9의 과정은 RET 명령어의 기능이며, 4~8의 과정은 호출되는 함수 측에서 코딩을 해 줘야 한다. 꽤 복잡한 과정을 거치며, 코드를 그냥 쓰는 것(인라인)보다 '''적어도 네 번'''의 메모리 접근을 더 요구하고, 인자를 전달하는 경우 '''적어도 인자의 개수만큼'''의 메모리 접근을 추가적으로 필요로 하는 등 매우매우매우 많은 시간과 자원을 잡아먹는다. 그러므로 함수를 사용할 때 원칙적으로는 이것이 꼭 필요한지 생각해 보는 것이 좋다. 다만 프로시저를 프로시저가 아닌 것처럼 사용하는 방법이 있다. 그것은 바로 [[C++]] 등에서 지원하는 [[인라인 함수]]이다. 인라인 함수를 사용하게 되면 컴파일러가 함수를 호출하는 것이 아니라(스택 프레임 등을 확보하고 프레임 포인터들을 바꾸는 것이 아니라), 인라인 함수 내의 내용으로 코드를 바꾸어 버린다. 따라서 코드를 그냥 쓰는 것과 다름없이 사용가능하다. 다만 위의 내용은 다소 낡은 내용인데, 현재는 대부분의 컴파일러 성능이 좋아진 터라 최적화 옵션을 주면 inline 지시자 없이도 자동으로 인라이닝을 해주기 때문이다. 또 하드웨어의 성능도 향상되어 현재 단순 프로시저 콜 오버헤드를 걱정해야 하는 시기는 이미 지났다고 볼 수 있다. 이제는 커널 튜닝/해킹을 하지 않는 이상 함수 콜 오버헤드를 걱정할 필요는 없다! 따지고 보면 [[객체 지향 프로그래밍]]은 vtable 참조 때문에 프로시저 지향 프로그래밍보다 함수 콜이 느린데도 잘만 쓴다. 예전 컴퓨터 기준으로 작성된 프로그래밍 기법 중에서 자주 찾아볼 수 있는 현상. 최근 프로그래밍은 성능도 성능이지만 편의성, 호환성, 생산성을 예전보다 중시하는 추세이다.저장 버튼을 클릭하면 당신이 기여한 내용을 CC-BY-NC-SA 2.0 KR으로 배포하고,기여한 문서에 대한 하이퍼링크나 URL을 이용하여 저작자 표시를 하는 것으로 충분하다는 데 동의하는 것입니다.이 동의는 철회할 수 없습니다.캡챠저장미리보기